Hi, ich bin Julian. Ich wohne in London und ich arbeite in einem Büro in London.

Da habe ich mir neulich diese Frage gestellt, was ist eigentlich dieses nervige Radio?

Die Personalabteilung und das Büromanagement sitzen direkt neben mir und die haben da so ein Radio unterm Tisch.

Es scheint keine Gamer zu geben in England und deswegen dudelt das Radio die ganze Zeit und es spielt immer den gleichen Sender.

Es ist immer nur ABBA und Queen und irgendwelche anderen Bands, von denen ich wahrscheinlich noch nie was gehört habe, weil ich einfach nicht alt genug bin dafür.

Magic Radio und irgendwann habe ich mich gefragt, sind das eigentlich immer die gleichen 20 Lieder?

Weil es fühlt sich echt so an. Es ist immer nur Dancing Queen und...

Ach, ja. Was macht man da?

Kopfhörer?

Kopfhörer, ja. Wir gucken uns mal die Webseitenquelltext an.

Von dieser Webseite.

Ja, also da ist jede Menge HTML, aber da ist zum Glück auch JavaScript und es sieht aus, als ob da eine React-Anwendung wäre.

Das ist ja ganz praktisch, da ist so eine riesige JSON-Struktur.

Das ist erstmal nicht schlecht, oder? Da gibt es irgendwie einen Tracknamen, einen Artistnamen und wann das gespielt wurde und eine ID auch.

Das ist ja super praktisch, da kann man ja Sachen mitmachen.

Das könnte man ja mal in eine Datenbank pumpen zum Beispiel.

Und die brauchen wir auch gar nicht zu normalisieren. Die vier Sachen, diese vier Dateninformationen reichen uns ja.

Wir nehmen die Spielzeit einfach mal als Unique, als Primärschlüssel, weil Lieder werden ja mehrfach gespielt, offensichtlich.

Wie Dancing Queen, gefühlt dreimal am Tag. Dazu mehr später.

Ja, das machen wir mal und dann brauchen wir einen kleinen Scraping-Job.

Da bietet sich der Mojo User Agent an. Wollte ich mal ausprobieren, ist ganz nett.

Ein bisschen Daten absaugen, ein bisschen JSON und dann pumpen wir das einfach in unsere Datenbank rein, machen Replays.

Weil wenn wir das alle paar Minuten laufen lassen und die Daten sind irgendwie für zwei Stunden lang auf der Webseite, dann haben wir natürlich Dubletten.

Ja, aber das geht. Und dann nehmen wir uns mal DBX Class und mit dem DBX Class Schema Loader produzieren wir uns da schnell ein paar Klassen für.

Das Result hier drüben, das Playlist Result ist vom Schema Loader erstellt und dann habe ich mein eigenes Result Set dazu gemacht.

Das Result Set brauchen wir, um da die Business Logik reinzupacken.

Und im Prinzip ist das immer nur irgendwelche Abfragen, also Search-Aufrufe, die dann ein weiteres Result Set ausliefern.

Und praktischerweise kann man ja die Result Sets chainen. Das heißt, man steckt da mehr Bedingungen rein und dann kommt ein neues Result Set raus.

Wir schauen uns das gleich mal an. Aber wir wollen ja Separation of Concerns.

Das braucht man nicht nur in Web-Anwendungen, sondern das kann man auch in Command Line Anwendungen nutzen.

Und eine Command Line Anwendung könnte dann zum Beispiel so aussehen.

Wir haben eine Playlist und dann sagen wir, ich hätte gerne den Top Artist für Yesterday.

Dann sagt sieben Plays Madonna. Like a virgin. Anderer Artist. Wer hat es erkannt?

Sehr gut. Sehr gut.

Ja, wir haben das Programm, wir haben den Command und wir haben einen Flag. So nennt man das typischerweise bei Command Line Applikationen.

Und da gibt es verschiedene Möglichkeiten, das zu implementieren.

Eine davon, die ich gerne vorstellen würde, ist Musics App Command.

Das ist im Prinzip ein Meshup aus Musics Get Opt und App Command.

Und es ist ziemlich einfach. Zurück zu unserem Tree.

Wir haben da dieses Skript. Playlist.pl. Und das sieht so aus, dass wir im Prinzip dieses Modul laden und ausführen und sonst nichts.

Ziemlich simpel. Und dann haben wir dieses Package. Das Extended. Das ist eine Subklasse von Musics App Command. Und sonst nichts.

Und dann haben wir für jeden einzelnen Command ein einzelnes Package. Wie zum Beispiel den Top Artist.

Da haben wir zwei Rollen. Eine für die Datenbank und eine für Zeit basiert.

Wir sehen gleich noch, warum das zwei verschiedene sind. Und dann haben wir eine Execute Sub. Die muss immer da sein.

Die hat drei Argumente. Interessantes neben Self natürlich, weil es ja Moose ist.

Das ist der ARCs Hash Ref. Wir holen uns dann das Result Set. Das kommt aus dieser WithDB Roll.

Und geben dann was aus. Alles relativ simpel. Nicht weiter darauf eingehen.

Die Rolle sieht wie folgt aus. Eine ganz normale Moose Rolle. Kann man halt damit reinkombinieren. Ist ja alles Moose.

Und da haben wir eben unsere Datenbank. Und dann connecten wir die. Und dann haben wir das Result Set.

Und das war's auch schon. Das Standard Result Set ist immer erstmal die ganze Playlist. Immer immer nur die eine Datenbank Tabelle.